完成醫院預約網站的主要畫面與操作流程規劃後，我原本以為下一步就是：
「開始把Figma的畫面切成HTML、CSS」
但實際上，如果直接看到一個畫面就開始寫HTML，很容易變成每個頁面都各寫一份。
所以在真正開始寫程式之前，我想先停下來思考一件事情：
Figma裡面設計好的畫面，到了Angular裡面要怎麼拆？
這也成為今天最重要的主題。
這次的專案不是單純做一個靜態網頁。
除了首頁之外，還有：
如果每一個頁面都從頭開始寫，很容易遇到一個問題：
很多東西其實會一直重複。
例如網站的Header。
首頁有Header，醫師查詢頁有Header，登入頁可能也有Header。
如果每一頁都重新寫一次，不但浪費時間，之後如果要修改，也必須一頁一頁改。
所以我開始思考：
「Figma裡面已經把重複使用的UI做成Component了，那到了Angular，這次的專案不是單純做一個靜態網頁。
除了首頁之外，還有：
醫師查詢
醫師詳細資訊
登入
註冊
預約掛號
預約成功
我的預約
預約詳細資訊
個人檔案
就醫資訊
醫院介紹
如果每一個頁面都從頭開始寫，很容易遇到一個問題：
很多東西其實會一直重複。
例如網站的 Header。
首頁有 Header，醫師查詢頁有 Header，登入頁可能也有 Header。
如果每一頁都重新寫一次：
Header
Header
Header
Header
不但浪費時間，之後如果要修改，也必須一頁一頁改。
所以我開始思考：
「Figma裡面已經把重複使用的UI做成Component了，到了Angular，應該也要採用同個概念」
在Figma階段，我已經開始把重複出現的介面整理成Component。
例如：
到了Angular，我希望這些設計也能轉換成實際可以重複使用的Component。
所以我開始建立這樣的對照關係：
Figma->Component->Angular Component
例如：
*Header
Header不需要每個頁面重新寫，只要建立一次，就可以在不同頁面使用。
醫師查詢頁會有很多醫師卡片。
如果每一張卡片都自己寫HTML：
Doctor Card 1
Doctor Card 2
Doctor Card 3
Doctor Card 4
程式會變得很難維護。
因此可以把醫師卡片設計成：
Doctor Card Component
之後只需要提供不同的醫師資料，就可以產生不同的卡片。
這樣就不需要為每一位醫師重新設計一個卡片。
按鈕也是一樣。
前面在Figma 裡，我已經統一了按鈕的設計與狀態。
到了Angular，我希望也能建立：
Button Component
讓網站中的按鈕維持一致的樣式。
例如：
而不是每個頁面都自己寫一套CSS。
除了單一Component 之外，我也開始思考：
整個Angular 專案到底要怎麼分？
目前我的網站功能大致可以分成：
App
|
|- Header
|- Router
|
|- Home
|
|- Doctor
| |- Doctor List
| |- Doctor Detail
|
|- Login
|- Register
|
|- Appointment
| |- Appointment Registration
| |- Appointment Success
|
|- My Appointment
| |- Appointment Detail
|
|- Profile
|
|- Hospital
|
|- Footer
這時候我才發現：
Figma的頁面規劃，其實可以幫助我思考程式的架構。
前面的User Flow不只是拿來畫流程圖。
Wireframe也不只是拿來決定畫面位置。
UI Design也不只是決定顏色。
這些設計最後都會影響真正的程式結構。
這也是我在這個階段開始注意到的一件事情。
一開始很容易產生一個想法：
「Figma有一個頁面，就建立一個Angular Component。」
但實際上不一定需要這樣。
例如：
醫師查詢頁
看起來是一個完整頁面。
但是裡面其實還可以拆成：
Doctor Search
|
|- Search Input
|- Department Filter
|- Doctor Card
|- Pagination
|- Footer
其中：
Doctor Search
比較接近一個頁面或功能。
而：
則是可以重複使用的UI元件。
所以我開始理解：
頁面是由Component組合而成，而不是每個頁面都是一整塊程式碼。
做到這裡，我覺得自己對Figma的理解也和一開始不太一樣了。
一開始使用Figma時，我比較在意：
但做到後面，我開始思考：
「這個東西之後會不會在其他地方再次出現？」
如果會，就值得思考能不能把它整理成Component。
例如：
這些不只是「畫面上的東西」。
它們其實也可以成為之後程式開發時的基礎。
所以我開始把設計從：
畫一個頁面
慢慢轉變成：
建立一套可以重複使用的UI
這也是我這次做專案時，第一次比較明顯感受到：
UI Design和Frontend Development其實是連在一起的。
這次專案我預計使用Angular作為前端框架。
在前面規劃技術時，我希望這個專案不只是把網站做出來，也能讓自己實際接觸企業開發常見的前端架構。
Angular本身採用Component的開發方式，這和我前面在Figma建立Component的思考方式很接近。
因此對我來說，剛好可以把前面做好的設計概念延續到程式開發。
簡單來說：
Figma Component->Angular Component
前面是在設計：
「這個UI要長什麼樣子？」
接下來則要開始思考：
「這個UI要怎麼變成真正可以運作的程式？」
除了Component，我也開始注意到另一個問題：
這麼多頁面要怎麼互相切換？
在Figma Prototype裡，我是透過Prototype Interaction把這些頁面串起來。
但到了Angular，就不能只靠Figma的Prototype。
之後需要透過Angular的Router，讓不同網址對應到不同頁面。
例如概念上：
/home
/doctors
/doctors/:id
/login
/appointments
/appointments/success
/my-appointments
/profile
這也讓我發現：
Prototype是模擬使用者怎麼操作，而Router是實際讓網站頁面可以被程式管理。
兩者目的不同，但前面的Prototype規劃可以幫助我思考之後的Router結構。
| Figma | Angular |
|---|---|
| Page | 頁面/功能 |
| Component | Angular Component |
| Instance | Component的使用 |
| Variant | Component的不同狀態 |
| Prototype | 實際網站的互動邏輯 |
| Prototype Flow | Router/程式流程 |
| Design System | 共用UI與樣式規則 |
這不是代表Figma和Angular的功能完全相同。
而是幫助我建立一個觀念：
Figma是設計階段，Angular是實作階段，但前面的設計決策可以直接影響後面的程式架構。
以前我可能會把「UI設計」和「寫程式」看成兩個完全不同的階段。
但這次自己從User Flow一路做到Figma Prototype後，我開始發現：
User Flow->Wireframe->UI Design->Component->Prototype->Angular
其實是一條完整的開發流程。
前面的每一個決定，都可能影響後面的實作。
例如：
如果前面沒有整理Component，
到了Angular就可能出現大量重複的HTML和CSS。
如果前面沒有想清楚頁面流程，
到了Router就可能不知道頁面之間應該怎麼連接。
如果前面沒有定義不同狀態，
到了實際開發時，就需要重新思考按鈕、FAQ、表單等UI要怎麼變化。
所以這一天我沒有急著開始寫程式。
反而先花時間思考：
「我要怎麼把Figma裡的設計，轉換成真正可以維護的前端架構？」
我覺得這是從「做畫面」開始進入「做系統」的一個重要轉折。
在這個階段，我主要把AI當成「開發前的討論對象」。
例如：
* 協助思考頁面如何拆分
* 討論哪些UI適合做成共用Component
* 整理Figma Component與Angular Component的對應概念
* 思考網站的頁面與Router結構
* 檢查目前的前端架構是否容易維護
但這次我沒有直接讓AI幫我產生完整Angular專案。
因為我希望在真正開始寫程式之前，先理解：
為什麼要這樣拆？
而不是直接拿一份程式碼開始修改。
iThome鐵人賽
看影片追技術